1. Field of the Invention
The present invention relates to a computer system, and deals more particularly with a method, system, and computer-readable code that dynamically selects program components based on current values of one or more changeable attributes, and downloads those components on demand during program execution.
2. Description of the Related Art
Computer programs often provide different access capabilities to different users, based upon a user's role or classification. For example, a payroll application may enable an employee to view his salary, year-to-date tax information, and other relevant payroll data, while a management status is required before a user can change the values of those fields--or before the user can view the same type of information for multiple employees. As another example, a software code library management system may enable users of all classifications to view code modules, but may limit the ability to change the modules to users whose log-on information indicates that they are developers authorized to make such changes. This log-on information may be in the form of a user password, user department number, or other identifying information.
This type of access control is provided by coding appropriate authorization checks into the software, so that only the intended users are allowed to execute certain parts of the code. If an unauthorized user attempts to access that part of the code, an error message may be issued, or the code may simply do nothing until the user selects something for which he is authorized.
In one scenario, the user of this type of software may have the entire application loaded on his workstation, giving him in effect a "private" copy of the software that is not shared with other users. Or, in a second scenario, the application software may physically reside at a server. Each user wishing to execute the application establishes a network connection to the server, so that a single copy of the software is shared by multiple users. Typically, the data that is accessed (e.g. the payroll information, or the stored code modules, discussed above) when using an application that performs authorization checking will be stored remotely from the user's workstation, in a data repository (such as a database) that is accessible to multiple users (again, by making a network connection to a server).
With the advent of programming languages and techniques that allow dynamic location of code modules during program execution, a third scenario is possible. Some portion of the application software is resident on the user's workstation, with additional modules being stored elsewhere. There are a number of reasons why this mode of operation may be desirable. For example, the amount of code stored on the user's workstation can be decreased when modules are stored remotely. In addition, the user can have access to updated versions of code more easily when modules are stored in a centralized remote location, and code maintenance can be simplified, because each user's individual machine does not need to be separately updated. One technique with which this mode of execution is supported is through use of the Remote Procedure Call ("RPC") protocol. With RPC, a programmer codes a module invocation (i.e. a procedure call) in the normal manner for the programming language in which he is writing, but only a "stub" for that module is generated during program compilation (where a "stub" is a special construct enabling the program to successfully compile without resolving the address of the referenced procedure). If the procedure is actually called during runtime, a request to execute the code will be forwarded to a server where the module is available (hence, the procedure call is a "remote" procedure call). That server will perform the function of the procedure, and return the results to the user's workstation, transparently to the user. (For a detailed description of RPC, refer to international standard ISO/IEC 11578, "Remote Procedure Call (RPC)", dated 1996.)
Another technique that enables operation in this third scenario, which is usable in object-oriented environments, is known as "DSOM", or "Distributed System Object Model". "SOM", or "System Object Model", is an International Business Machines Corporation ("IBM") implementation of the CORBA (Common Object Request Broker Architecture) standard developed by the Object Management Group. (SOM is a registered trademark of IBM, and CORBA is a registered trademark of Object Management Group, Inc.) SOM defines a way to create objects that can be accessed by programs without regard to the programming language in which the program is written, the specific compiler used to compile the programs, etc. DSOM, also from IBM, extends the SOM by defining a way to distribute SOM objects, so that they can be accessed by remotely executing applications. (The details of CORBA, SOM, and DSOM are beyond the scope of this discussion. Reference may be made to "The Common Object Request Broker: Architecture and Specification", OMG Document Number 91.12.1 Revision 1.1, for more information on CORBA, and to "SOMobjects Publications", IBM document number S96F-8649, for more information on SOM and DSOM.)
The Java programming language provides yet another technique for operating with only some portion of the executable program being loaded on the user's workstation. (Java is a trademark of Sun Microsystems, Inc.) Whereas RPC and DSOM provide for accessing remotely-stored procedures and objects, Java provides a different approach. When executing a Java applet, code modules are loaded from their remote storage onto the user's workstation if and when they are needed (i.e. if they are actually invoked during execution), so that execution occurs locally. (In addition, Java Remote Method Invocation, or "RMI", provides for execution of remotely-located Java methods, in a similar manner to that described above for remote execution using RPC and DSOM.)
The three techniques that have been described for operating in the third scenario described above all provide for code sharing--whether by accessing a remotely-stored, shared copy of the code (as described for RPC, DSOM, and RMI), or by downloading a copy to users needing the code (as described for Java applets). However, each of these techniques has in common that a single, predetermined copy of the software will be accessed. If that software contains code that is authorization-protected, as described above, then the software downloaded onto the user's workstation will often contain some amount of code that this user cannot access (because the user likely will not qualify for all the defined access levels). This results in wasted storage space on the user's workstation, and a decrease in execution efficiency. While this may be merely a less-than-optimal working environment for some users, it can be a very serious problem for users of workstations when storage space is at a premium. For example, the user may be using a handheld computer such as the WorkPad from IBM. ("WorkPad" is a registered trademark of IBM.) Storage space on handheld computers is typically limited to several megabytes, in order to keep the device small and lightweight. (Storage constraints may exist on much larger machines as well, at a point in time, as is commonly known.)
In addition to wasting space by storing inaccessible authorization-protected code, space is also wasted if the downloaded software provides for execution in environments that are not supported by the user's workstation. For example, a module that displays the user interface may include code for several different types of display devices, and query the user's hardware at run-time to determine which device type is installed--and accordingly, which portion of the software to execute. Or, a report-generating software routine may contain code to generate the report on the display device as well as by printing it on an attached printer, leaving the final output choice to the user. If the user does not have a printer attached to his computer, then the printing logic (which may be extensive) is unusable. The greater the number of different situations provided for by the software, the more likely it is that this type of redundant code will exist.
Accordingly, what is needed is a technique whereby a program component can be dynamically selected and downloaded, based on current values of one or more changeable attributes. The present invention provides a technique whereby multiple versions of a program component are available, and a specific version can be dynamically selected and downloaded based on current attribute values. Attribute values may represent a user's authorization privileges, current working environment, preferences, network connection type, status, etc. In this manner, software can be optimized for particular users or groups of users, or particular environments of hardware and/or software, while still providing applications that are usable by a wide range of users in a wide range of operating environments.